本篇是最後五天方法回顧的最後一篇，也是全系列的收束。

本篇要回答：怎麼分辨一項改善措施是真的防再發，還是只是多了一份文件？

無效措施的五種經典款

「下次注意」「加強教育訓練」「多印一行 log」「重開服務」「修掉這一行就好」——五句話的共同點：說完的當下就完成了它們的全部功能，也就是讓會議可以散會。它們沒有負責人、沒有期限、沒有驗證方式，三個月後無從稽核它們存在過。

改善措施的最低契約

每一項措施必須寫齊：改善內容、對應的原因或促成因素（Day 29 的帳目編號）、負責人、完成期限、驗證方式、回退方法、新增成本與風險、後續追蹤日期，以及最終問句——它是否真的降低事故發生率或縮短發現時間。

其中兩欄最常暴露空心措施。「驗證方式」：Day 15 與 Day 20 的標準是能在最小重現上演示「有它就攔住、沒它就放行」——演示不出來的措施是裝飾。「新增成本與風險」：宣稱零成本的措施幾乎必然沒被想清楚——型別註記要維護、分批修正拖慢流程、狀態機增加元件；誠實標價，措施才可能被持續執行而不是被默默繞過。

還有一種偽裝最好的無效措施：新表單、新打勾欄位。分辨方式是問一句——填錯或不填，會有任何系統性的後果嗎？不會的話，它只是把「下次注意」印成了表格。

全系列最後五問

面對任何一句「完成了」，這個系列留下的檢查程序：

1. 我們宣稱完成的是哪一個結果？
2. 有哪些直接證據支持這個主張？
3. 從輸入到外部效果的事件軌跡完整嗎？
4. 已確認原因、促成因素與未知事項分開了嗎？
5. 改善措施如何證明有效，而不只是多一份文件？

五問對應五個故事的教訓，也對應五日循環的五個階段——它們是同一套方法的兩種展開。

系列結語

It Works on My Machine 不是一句應該被禁止的話。它至少提供了一個調查起點：在哪一個環境、哪一組版本、哪一條路徑、哪一個條件下，它確實正常？

真正需要避免的，是拿局部成功替整套系統結案。當 IDE、Python、lint、ORM、Publisher 與工程師都說自己沒有問題時，我們仍然要回到使用者真正需要的結果，保存證據、重建事件軌跡，並誠實區分已確認、推論與未知。

三十天前，這句話是我的藉口；三十天後，它是我的起點。

It Works on My Machine 不是結論，而是事故調查與重新學習的起點。